Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / CCITT / 1992 / X / x500.asc < prev next >

Wrap

Text File | 1993-07-15 | 46.8 KB | 782 lines

The drawings contained in this Recommendation have been done in AUTOCAD Recommendation X.500 THE DIRECTORY - OVERVIEW OF CONCEPTS, MODELS AND SERVICES 1) (Melbourne, 1988) CONTENTS 0 Introduction 1 Scope and field of application 2 References 3 Definitions 3.1 OSI reference model definitions 3.2 Basic directory definitions 3.3 Directory model definitions 3.4 Distributed operation definitions 4 Abbreviations 5 Overview of the directory 6 The directory information base (DIB) 7 The directory service 7.1 Introduction 7.2 Service qualification 7.3 Directory interrogation 7.4 Directory modification 7.5 Other outcomes 8 The distributed directory 8.1 Functional model 8.2 Organizational model 8.3 Operation of the model 9 Directory protocols Annex A - Applying the directory A.1 The directory environment A.2 Directory service characteristics A.3 Patterns of use of the directory A.4 Generic applications 1) Recommendation X.500 and ISO 9594-1, The Directory - Overview of Concepts, Models and Services, were developed in close collaboration and are technically aligned. Fascicle VIII.8 - Rec.X.500 PAGE1 0 Introduction 0.1 This document, together with the others of the series, has been produced to facilitate the interconnection of information processing systems to provide directory services. The set of all such systems, together with the directory information which they hold, can be viewed as an integrated whole, called the Directory. The information held by the Directory, collectively known as the Directory Information Base (DIB), is typically used to facilitate communication between, with or about objects such as application entities, people, terminals and distribution lists. 0.2 The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum of technical agreement outside of the interconnection standards themselves, the interconnection of information processing systems: - from different manufacturers; - under different managements; - of different levels of complexity; and - of different ages. 0.3 This Recommendation introduces and models the concepts of the Directory and of the DIB and overviews the services and capabilities which they provide. Other Recommendations make use of these models in defining the abstract service provided by the Directory, and in specifying the protocols through which this service can be obtained or propagated. 1 Scope and field of application 1.1 The Directory provides the directory capabilities required by OSI applications, OSI management processes, other OSI layer entities, and telecommunication services. Among the capabilities which it provides are those of "user-friendly naming" whereby objects can be referred to by names which are suitable for citing by human use s (though not all objects need have user- friendly names); and "name- to-address mapping" which allows the binding between objects and their locations to be dynamic. The latter capability allows OSI networks, for example, to be "self-configuring" in the sense that addition, removal and the changes of object location do not affect OSI network operation. 1.2 The Directory is not intended to be a general-purpose data base system, although it may be built on such systems. It is assumed, for instance, that, as is typical with communications directories, there is a considerably higher frequency of "queries" than of updates. The rate of updates is expected to be governed by the dynamics of people and organizations, rather than, for example, the dynamics of networks. There is also no need for instantaneous global commitment of updates: transient conditions where both old and new versions of the same information are available, are quite acceptable. 1.3 It is a characteristic of the Directory that, except as a consequence of differing access rights or unpropagated updates, the results of directory queries will not be dependent on the identity or location of the enquirer. This characteristic renders the Directory unsuitable for some telecommunications applications, for example some types of routing. 2 References Recommendation X.200 -Open Systems Interconnection - Basic Reference Model. Recommendation X.208 -Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). Recommendation X.501 - The Directory - Models. Recommendation X.509 - The Directory - Authentication framework. Recommendation X.511 - The Directory - Abstract Service Definition. Recommendation X.518 - The Directory - Procedures for Distributed Operation. Recommendation X.519 - The Directory - Protocol Specifications. Recommendation X.520 - The Directory - Selected Attribute Types. Recommendation X.521 - The Directory - Selected Object Classes. Recommendation X.219 - Remote Operations - Model, Notation and Service Definition. Recommendation X.229 - Remote Operations - Protocol Specification. 3 Definitions The definitions contained in this make use of the abbreviations defined in S 4. 3.1 OSI reference model definitions This Recommendation is based on the concepts developed in Recommendation X.200, and makes use of the following terms therein defined: PAGE4 Fascicle VIII.8 - Rec.X.500 a) application-entity; b) Application Layer; c) application process; d) application protocol data unit; e) application service element. 3.2 Basic directory definitions a) The Directory: a collection of open systems cooperating to provide directory services; b) Directory Information Base (DIB): the set of information managed by the Directory; c) (Directory) user: the end user of the Directory, i.e. the entity or person which accesses the Directory. 3.3 Directory model definitions This Recommendation makes use of the following terms defined in Recommendation X.501. a) Administration Directory Management Domain; b) alias; c) attribute; d) attribute type; e) attribute value; f) Directory Information Tree (DIT); g) Directory Management Domain (DMD); h) Directory System Agent (DSA); i) Directory User Agent (DUA); j) distinguished name; k) entry; l) name; m) object (of interest); n) Private Directory Management Domain; o) relative distinguished name; p) root; q) schema; r) subordinate object; s) superior entry; t) superior object; u) tree. 3.4 Distributed operation definitions This Recommendation makes use of the following terms defined in Recommendation X.518: a) chaining; Fascicle VIII.8 - Rec.X.500 PAGE1 b) multicasting; c) referral. 4 Abbreviations ADDMD Administration Directory Management Domain DAP Directory Access Protocol DIB Directory Information Base DIT Directory Information Tree DMD Directory Management Domain DSA Directory System Agent DSP Directory System Protocol DUA Directory User Agent OSI Open Systems Interconnection PRDMD Private Directory Management Domain RDN Relative Distinguished Name 5 Overview of the Directory 5.1 The Directory is a collection of open systems which cooperate to hold a logical data base of information about a set of objects in the real world. The users of the Directory, including people and computer programs, can read or modify the information, or parts of it, subject to having permission to do so. Each user is represented in accessing the Directory by a Directory User Agent (DUA), which is considered to be an application-process. These concepts are illustrated in Figure 1/X.500. FIGURE 1/X.500 - -T0704210-88 Note - This series of Recommendations refers to the Directory in the singular, and reflects the intention to create, through a single, unified, name space, one logical directory composed of many systems and serving many applications. Whether or not these systems choose to interwork will depend on the needs of the applicatio s they support. Applications dealing with non- intersecting worlds of objects, may have no such need. The single name space facilitates later interworking should the needs change. 5.2 The information held in the Directory is collectively known as the Directory Information Base (DIB). Clause 6 of this Recommendation overviews its structure. 5.3 The Directory provides a well-defined set of access capabilities, known as the abstract service of the Directory, to its users. This service, which is overviewed in 7 of this Recommendation provides a simple modification and retrieval capability. This can be built on with local DUA functions to provide the capabilities required by the end-users. 5.4 It is likely that the Directory will be distributed, perhaps widely distributed, both along functional and organizational lines. 8 overviews the corresponding models of the Directory. These have been developed in order to provide a framework for the cooperation of the various components to provide an integrated whole. 5.5 The provision and consumption of the Directory services requires that the users (actually the DUAs) and the various functional components of the Directory should cooperate with one another. In many cases this will require cooperation between application processes in different open systems, which in turn requires standardized application protocols, overviewed in 9, to govern this cooperation. 5.6 The Directory has been designed so as to support multiple applications, drawn from a wide range of possibilities. The nature of the application supported will govern which objects are listed in the Directory, which users will access the information, and which kinds of access they will carry out. Applications may be very specific, such as the provision of distribution lists for electronic mail, or generic, such as the "inter-personal communications directory" application. The Directory provides the opportunity to exploit commonalities among the applications: - a single object may be relevant to more than one application; perhaps even the same piece of information about the same object may be so relevant. To support this, a number of object classes and attribute types are defined, which will be useful across a range of applications. These definitions are contained in Recommendations X.520 and X.521: - certain patterns of use of the Directory will be common across a range PAGE4 Fascicle VIII.8 - Rec.X.500 of applications: this area is overviewed further in Annex A. 6 The Directory Information Base (DIB) Note - The DIB, and its structure, are defined in Recommendation X.501. 6.1 The DIB is made up of information about objects. It is composed of (directory) entries, each of which consists of a collection of information on one object. Each entry is made up of attributes, each with a type and one or more values. The types of attribute which are present in a particular entry are dependent on the class of object which the entry describes. 6.2 The entries of the DIB are arranged in the form of a tree, the Directory Information Tree (DIT) where the vertices represent the entries. Entries higher in the tree (nearer the root) will often represent objects such as countries or organizations while entries lower in the tree will represent people or application processes. Note - The services defined in this Recommendation operate only on a tree- structured DIT. This Recommendation does not preclude the existence in the future of other structures (as the need arises). 6.3 Every entry has a distinguished name, which uniquely and unambiguously identifies the entry. These properties of the distinguished name are derived from the tree structure of the information. The distinguished name of an entry is made up of the distinguished name of its superior entry, together with specially nominated attribute values (the distinguished values) from the entry. 6.4 Some of the entries at the leaves of the tree are alias entries, while all other entries are object entries. Alias entries point to object entries, and provide the basis for alternative names for the corresponding objects. 6.5 The Directory enforces a set of rules to ensure that the DIB remains well formed in the face of modifications over time. These rules, known as the Directory schema, prevent entries having the wrong types of attributes for its object class, attribute values being of the wrong form for the attribute type, and even entries having subordinate entries of the wrong class. 6.6 Figure 2/X.500 illustrates the above concepts of the DIT and its components. FIGURE 2/X.500 - T0704220-88 6.7 Figure 3/X.500 gives a hypothetical example of a DIT. The tree provides examples of some of the types of attributes used to identify different objects. For example the name: {C = GB, L = Winslow, O = Graphic Services, CN = Laser Printer} identifies the application entity "Laser Printer" which has in its distinguished name the geographical attribute of Locality. The residential person John Jones, whose name is GB {C = GB, L = Winslow, CN = John Jones} has the same geographical attribute in his distinguished name. FIGURE 3/X.500 - T0704230-88 6.8 The growth and form of the DIT, the definition of the Directory schema, and the selection of distinguished names for entries as they are added, is the responsibility of various authorities, whose hierarchical relationship is reflected in the shape of the tree. The authorities must ensure, for example, that all of the entries in their jurisdiction have unambiguous distinguished names, by carefully managing the attribute types and values which appear in those names. Responsibility is passed down the tree from superior to subordinate authorities, with control being exercised by means of the schema. 7 The Directory service Note - The definition of the abstract service of the Directory can be found in Recommendation X.511. 7.1 Introduction 7.1.1 This provides an overview of the service provided to users, as represented by their DUAs, by the Directory. All services are provided by the Directory in response to requests from DUAs. There are requests which allow interrogation of the Directory, as described in S 7.3, and those for modification, as described in 7.4. In addition, requests for service can be qualified, as described in S 7.2. The Directory always reports the outcome of each request that is made of it. The form of the normal outcome is specific to the request, and is evident from the description of the request. Most abnormal outcomes are common to several requests. The possibilities are described in 7.5. Fascicle VIII.8 - Rec.X.500 PAGE1 7.1.2 A number of aspects of the eventual directory service are not presently provided by the standards specified in this series of Recommendations. The corresponding capabilities will, therefore, need to be provided as a local function until such time as a standardized solution is available. These capabilities include: - addition and deletion of arbitrary entries, thus allowing a distributed Directory to be created; - the management of access control (i.e. granting or withdrawing permission for a particular user to carry out a particular access on a particular piece of information); - the management of the Directory schema; - the management of knowledge information; - the replication of parts of the DIB. Note - This list is not necessarily exhaustive. 7.1.3 The Directory ensures that changes to the DIB, whether the result of a Directory service request, or by some other (local) means, result in a DIB which continues to obey the rules of the Directory schema. 7.1.4 A User and the Directory are bound together for a period of time at an access point to the Directory. At the time of binding, the User and the Directory optionally verify each other's identity. 7.2 Service qualification 7.2.1 Service controls A number of controls can be applied to the various service requests, primarily to allow the user to impose limits on the use of resources which the Directory must not surpass. Controls are provided on, among other things: the amount of time, the size of the results, the scope of search the interaction modes, and on the priority of the request. 7.2.2 Security parameters Each request may be accompanied by information in support of security mechanisms for protecting the Directory information. Such information may include the user's request for various kinds of protection; a digital signature of the request, together with information to assist the correct party to verify the signature. 7.2.3 Filters A number of requests whose outcome involves information from or concerning a number of entries, may carry with them a filter. A filter expresses one or more conditions that an entry must satisfy in order to be returned as part of the outcome. This allows the set of entries returned to be reduced to only those relevant. 7.3 Directory interrogation 7.3.1 Read A read request is aimed at a particular entry, and causes the values of some or all of the attributes of that entry to be returned. Where only some attributes are to be returned, the DUA supplies the list of attribute types of interest. 7.3.2 Compare A compare request is aimed at a particular attribute of a particular entry, and causes the Directory to check whether a supplied value matches a value of that attribute. Note - For example, this can be used to carry out password checking, where the password, held in the Directory, might be inaccessible for read, but accessible for compare. 7.3.3 List A list request causes the Directory to return the list of immediate subordinates of a particular named entry in the DIT. 7.3.4 Search A search request causes the Directory to return information from all of the entries within a certain portion of the DIT which satisfy some filter. The information returned from each entry consists of some or all of the attributes of that entry, as with read. 7.3.5 Abandon An abandon request, as applied to an outstanding interrogation request, informs the Directory that the originator of the request is no longer interested in the request being carried out. The Directory may, for example, cease processing the request, and may discard any results so far achieved. PAGE4 Fascicle VIII.8 - Rec.X.500 7.4 Directory modification 7.4.1 Add entry An add entry request causes a new leaf entry (either an object entry, or an alias entry) to be added to the DIT. Note - In its present form this service is intended to be used to add entries which will remain as leaves, such as entries for people or application entities, rather than to add whole subtrees by repeated applications of this service. It is envisaged that the service will be enhanced in the future to cater to the more general case. 7.4.2 Remove entry A remove entry request causes a leaf entry to be removed from the DIT. Note - As with add entry, this service is presently intended for operation on "true leaf" entries, and will be enhanced in the future for the general case. 7.4.3 Modify entry A modify entry request causes the Directory to execute a sequence of changes to a particular entry. Either all of the changes are made, or none of them, and the DIB is always left in a state consistent with the schema. The changes allowed include the addition, removal, or replacement of attributes or attribute values. 7.4.4 Modify relative distinguished name A modify relative distinguished name (RDN) request causes the relative distinguished name of a leaf entry (either an object entry or an alias entry) in the DIT to be modified by the nomination of different distinguished attribute values. 7.5 Other outcomes 7.5.1 Errors Any service may fail, for example because of problems with the user supplied parameters, in which case an error is reported. Information is returned with the error, where possible, to assist in correcting the problem. However, in general, only the first error encountered by the Directory is reported. Besides the above-mentioned example of problems with the parameters supplied by the user (particularly invalid names for entries or invalid attribute types), errors may arise from violations of security policy, schema rules, and service controls. 7.5.2 Referrals A service may fail because the particular access point to which the DUA is bound is not the most suitable for carrying out the request, e.g. because the information affected by the request is (logically) far away from the access point. In this case the Directory may return a referral, which suggests an alternative access point at which the DUA can make its request. Note - The Directory and the DUA may each have a preference as to whether referrals are used, or whether the requests are chained (see S 8.3.3.2). The DUA can express its preference by means of service controls. The Directory makes the final decision as to which approach is used. 8 The distributed Directory Note - the models of the directory are defined in Recommendation X.501 while the procedures for the operation of the distributed Directory are specified in Recommendation X.518. 8.1 Functional model The functional model of the Directory is shown in Figure 4/X.500. FIGURE 4/X.500 - T0704240-88 A Directory System Agent (DSA) is an OSI application process which is part of the Directory and whose role is to provide access to the DIB to DUAs and/or other DSAs. A DSA may use information stored in its local data base or interact with other DSAs to carry out requests. Alternatively, the DSA may direct a requestor to another DSA which can help carry out the request. Local data bases are entirely implementation dependent. 8.2 Organizational model 8.2.1 A set of one or more DSAs and zero or more DUAs managed by a single organization may form a Directory Management Domain (DMD). The organization concerned may or may not elect to make use of this series of Recommendations to govern the communications among the functional components within the DMD. 8.2.2 Subsequent Recommendations specify certain aspects of the behaviour of DSAs. For this purpose, a group of DSAs within one DMD may, at the option of the organization which manages the DMD, behave as a single DSA. Fascicle VIII.8 - Rec.X.500 PAGE1 8.2.3 A DMD may be an Administration DMD (ADDMD), or a Private DMD (PRDMD), depending on whether or not it is being operated by a public telecommunications organization. Note - It should be recognized that the provision of support for private directory systems by CCITT members falls within the framework of national regulations. Thus, the technical possibilities described may or may not be offered by an Administration which provides directory services. The internal operation and configuration of private DMDs is not within the scope of envisaged CCITT Recommendations. 8.3 Operation of the model 8.3.1 The DUA interacts with the Directory by communicating with one or more DSAs. A DUA need not be bound to any particular DSA. It may interact directly with various DSAs to make requests. For some administrative reasons, it may not always be possible to interact directly with the DSA which needs to carry out the request, e.g. to return some directory information. It is also possible that the DUA can access the Directory through a single DSA. For this purpose, DSAs will need to interact with each other. 8.3.2 The DSA is concerned with carrying out the requests of DUAs and with obtaining the information where it does not have the necessary information. It may take the responsibility to obtain the information by interacting with other DSAs on behalf of the DUA. 8.3.3 A number of cases of request handling have been identified, as illustrated in Figures 57/X.500, and described below. 8.3.3.1 In Figure 5a/X.500, the DSA C receives a referral from DSA A and is responsible for either conveying the request to the DSA B (named in the referral from DSA A) or conveying the referral back to the originating DUA. FIGURE 5a/X.500 - T0704250-88 Note - If DSA C returns the referral to the DUA, the "request (to B)" will not occur. Similarly, if DSA C conveys the request to DSA B, it will not return a referral to the DUA. In Figure 5b/X.500, the DUA receives the referral from DSA C and is responsible for reissuing the request directly to DSA A (named in the referral from DSA C). FIGURE 5b/X.500 - 0704260-88 8.3.3.2 Figure 6/X.500 shows DSA chaining, whereby the request can be passed through several DSAs before the response is returned. FIGURE 6/X.500 - T0704270-88 8.3.3.3 Figure 7/X.500 shows multicasting, where the DSA associated with the DUA carries out the request by forwarding it to two or more other DSAs, the request to each DSA being identical. FIGURE 7/X.500 - T0704280-88 8.3.4 All of the approaches have their merits. For example, the approach in Figure 5/X.500 may be used where it is desirable to offload the burden from the local DSA. In other circumstances, a hybrid approach that combines a more elaborate set of functional interactions may be needed to satisfy the initiator's request, as illustrated in Figure 8/X.500. FIGURE 8/X.500 - T0704290-88 9 Directory protocols Note - The OSI application layer protocols defined to allow DUAs and DSAs in different open systems to cooperate are specified in Recommendation X.519. 9.1 There are two Directory protocols: - the Directory Access Protocol (DAP), which defines the exchange of requests and outcomes between a DUA and a DSA; - the Directory System Protocol (DSP), which defines the exchange of requests and outcomes between two DSAs. 9.2 Each protocol is defined by an application context, each containing a set of protocol elements. For example, the DAP contains protocol elements associated with interrogating and modifying the Directory. 9.3 Each application context is made up of application service elements. These application service elements are defined to use the Remote Operations Service PAGE4 Fascicle VIII.8 - Rec.X.500 (ROS) of Recommendation X.219 to structure and support their interactions. Thus the DAP and DSP are defined as sets of remote operations and errors using the ROS notation. ANNEX A (to Recommendation X.500) Applying the Directory This annex is not an integral part of this Recommendation. A.1 The Directory environment Note - In this S, the term "network" is used with its general meaning to denote the set of interlinked systems and processes relevant to any telecommunications service, not only one which relates to the OSI network layer. The Directory exists in and provides services in the following environment: a) many telecommunications networks will be on a large scale, and will constantly undergo change: 1) objects of various kinds will enter and leave the network without warning and may do so either singly or in groups; 2) the connectivity of the objects (particularly network nodes) will change, owing to the addition or removal of paths between them; 3) various characteristics of the objects, such as their addresses, availability, and physical locations, may change at any time; b) although the overall rate of changes is high, the useful lifetime of any particular object is not short. An object will typically be involved in communications much more frequently that it will change its address, availability, physical location, etc.; c) the objects involved in current telecommunications services are typically identified by numbers or other strings of symbols, selected for their ease of allocation or processing but not for ease of use by human beings. A.2 Directory service characteristics The need for directory capabilities arises from: a) the desire to isolate (as far as possible) the user of the network from the frequent changes to it. This can be accomplished by placing a "level of indirection" between the users and the objects with which they deal. This involves the users referring to objects by name, rather than by, for example, address. The Directory provides the necessary mapping service; b) the desire to provide a more "user-friendly" view of the network. For example, the use of aliases, the provision of "yellow-pages" (see A.3.5) etc., helps to relieve the burden of finding and using network information. The Directory allows users to obtain a variety of information about the network, and provides for the maintenance, distribution and security of that information. A.3 Patterns of use of the directory Note - This subclause is concerned only with Directory retrieval: it is assumed that the Directory modification services are used solely to maintain the DIB in the form necessary for the application over time. A.3.1 Introduction The Directory service is defined in these standards in terms of particular requests that a DUA can make and the parameters of them. An application designer is likely, however, to think in more goal-oriented terms when considering the information retrieval requirements of the Directory in that application. Accordingly, this clause describes a number of high-level patterns of use of the Directory service that are likely to be relevant to many applications. A.3.2 Look-up The straight Directory look-up is likely to be the most frequent type of query of the Directory. It involves the DUA supplying the distinguished name of an object, together with an attribute type. The Directory will return any value(s) corresponding that attribute type. This is a generalization of the classic directory function, which is obtained when the attribute type requested corresponds to a particular type of address. Attribute types for various kinds of address are standardized, including OSI PSAP address, Message Handling O/R address, and telephone and telex numbers. Look-up is supported by the read service, which also provides the Fascicle VIII.8 - Rec.X.500 PAGE1 following further generalizations: - look-up can be based upon names other than the distinguished name of the object, e.g. aliases; - the values from a number of attribute types can be requested with a single request: the extreme case being that the values of all attributes in the entry are to be returned. A.3.3 User-friendly naming Names can be given to objects in such a way as to maximize the chances that these names can be predicted (or perhaps remembered) by human users. Names which have this property would typically be made up of attributes which are somehow inherent to the object, rather than being fabricated for the purpose. The name of an object will be common among all of the applications which refer to it. A.3.4 Browsing In many human-oriented uses of the Directory, it may not be possible for the user (or DUA) to directly quote a name, user-friendly or otherwise, for the object about which information is sought. However, perhaps the user will "know it when he sees it". The browsing capability will allow a human user to wander about the DIB looking for the appropriate entries. Browsing is accomplished by combinations of the list and search services, possibly in conjunction with read (although the search service includes the capability of read). A.3.5 "Yellow Pages" There are a variety of ways to provide a "Yellow Pages" type capability. The simplest is based upon filtering, using assertions about particular attributes whose values are the categories (e.g. the "Business Category" attribute type defined in Recommendation X.520). This approach does not require any special information being set-up in the DIT, except to ensure that the requisite attributes are present. However, in the general case, it may be expensive to search where there is a large population because filtering requires the generation of the universal set which is to be filtered. An alternative approach is possible, based upon the setting up of special subtrees, whose naming structures are designed especially for "Yellow Pages" type searching. Shown in Figure A1/X.500 is an example of a "Yellow Pages" subtree populated by alias entries only. In reality, the entries within the "Yellow Pages" subtrees may be a mixture of object and alias entries, so long as there exists only one object entry for each object stored in the Directory. FIGURE A-1/X.500 - T0704300-88 A.3.6 Groups A group is a set whose membership can change over time by explicit addition and removal of members. The group is an object, as are its members. The Directory can be requested to: - indicate whether or not a particular object is a member of a group; - list the membership of a group. Groups are supported by having the entry for the group contain a multiple valued "Member" attribute (such an attribute type is defined in Recommendation X.520). The two capabilities mentioned can then be carried out by means of compare and read respectively. A member of a group could itself be a group, if this is meaningful for the application. However, the necessary recursive verification and expansion services would have to be created by the DUA out of the non-recursive versions provided. A.3.7 Authentication Many applications require the objects taking part to offer some proof of their identify before they are permitted to carry out some action. The Directory provides support for this authentication process. (As a separate matter, the Directory itself requires its users to authenticate themselves, so as to support access control). The more straightforward approach to authentication, called "simple authentication", is based upon the Directory holding a "User Password" attribute in the entry for any user that wishes to be able to authenticate itself to a Service. At the request of the Service, the Directory will confirm or deny that a particular value supplied is actually the user's password. This avoids the user needing a different password for every Service. In cases where the exchange of passwords in a local environment that uses simple authentication is considered to PAGE4 Fascicle VIII.8 - Rec.X.500 be inappropriate, the Directory optionally provides means to protect those passwords against replay or misuse by a one way function. The more complex approach, called "strong authentication" is based upon public key cryptography, where the Directory acts as a repository of users' public encryption keys, suitably protected against tampering. The steps that users can take to obtain each other's public keys from the Directory, and then to authenticate with each other using them, are described in detail in Recommendation X.509. A.4 Generic applications A.4.1 Introduction There are a number of generic applications which can be imagined as implicitly supported by the Directory: applications which are not specific to any particular telecommunications service. Two such applications are described herein: the inter-personal communications directory and the inter- system communications directory (for OSI). Note - Authentication, described in the previous subclause as an "access pattern" could alternatively be thought of as a generic Directory application. A.4.2 Inter-personal communications The intent of this application is to provide humans or their agents with information on how to communicate with other humans, or groups thereof. The following classes of objects are certainly involved: person, organizational role and group. Many other classes are involved too, perhaps in a less direct way, including: country, organization, organizational unit. The attribute types concerned, other than those used in naming, are generally the addressing attributes. Typically the entry for a particular person will have the addresses corresponding to each of the communication methods by which that person can be reached, selected from an open-ended list which includes at least the following: telephony, electronic mail, telex, ISDN, physical delivery (e.g. the postal system), facsimile. In some cases, such as electronic mail, the entry will have some additional information such as the types of information which the user's equipment can handle. If authentication is to be supported, then User Password and/or Credentials will be needed. The naming schemes used for the vario s object classes should be user- friendly, with aliases being set up as appropriate to provide alternative names, provide continuity after a name change, etc. The following access patterns will be manifested in this application: look-up, user-friendly naming, browsing, "Yellow Pages", and groups. To varying degrees, authentication will also be used. A.4.3 Inter-system communications (for OSI) According to the OSI Reference Model, two Directory functions are required in OSI, one, operating in the application layer, which maps application-titles onto presentation-addresses, and one, in t e network layer, which maps NSAP- addresses onto SNPA-addresses (SNPA = Subnetwork Point of Attachment). Note - For the remainder of this , only the application layer case is dealt with. This function is carried out by consulting the Directory if the information required to accomplish the mapping is not conveniently available by other means. The users are application-entities and the object classes of interest are also applicationentities, or subclasses thereof. The main attribute type concerned, other than those used for naming, is the presentationaddress. Other attribute types, not viewed as necessary for the directory function itself, could support verifying or finding out the application entity type, or the lists of application contexts, abstract syntaxes, etc. supported. The authentication-related attribute types could also be relevant. The main access pattern to be manifested will be look-up. Fascicle VIII.8 - Rec.X.500 PAGE1